Skip to content

Release/2025.05 #4382

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 225 commits into
base: main
Choose a base branch
from
Open

Release/2025.05 #4382

wants to merge 225 commits into from

Conversation

Geenz
Copy link
Collaborator

@Geenz Geenz commented Jul 17, 2025

as of = 2025-07-02 for PV deploy
build = https://github.com/secondlife/viewer/releases/tag/Second_Life_Project%23bca9ba9b-glTF_Mesh_Import
cohort = glTF Mesh Import
deployed = https://github.com/secondlife/viewer/releases/tag/Second_Life_Project%23bca9ba9b-glTF_Mesh_Import
desired = 0
relnotes:

2025.05

Welcome to 2025.05! This release focuses on bringing glTF mesh import to Second Life, and enhanced frametime metrics!

We are very excited to begin offering a new mesh upload option, following the glTF mesh standard. Now content creators may explore the endless possibilities of importing glTF models with .gltf and .glb file types.

This is an early Alpha release and we have done our best to smooth out the rough edges and already resolved many bugs and crashes. While we know there are more to be found, we feel this is ready to start receiving general feedback from the community.

Generally, this should have similar constraints to COLLADA upload, with some key limitations:

  • We currently do not support a unified material upload solution in the mesh importer.

Known Issues

  • Joint overrides may not work for all meshes.

Existing Mesh Constraints

As a reiteration of our existing mesh constraints:

  • Sub-meshes may not have more than 8 materials
    • Sub-meshes with more than 8 materials will be split into more meshes.
  • Sub-meshes may not have more than 65,535 vertices
    • Sub-meshes that have more than this limit will be split into more meshes.
  • You may not have more than four joint weights per vertex on rigged meshes
  • Rigged meshes must be rigged in accordance with with one of the Second Life skeletons, which may be found at https://github.com/secondlife/creator-resources

These constraints will not be changing with this first release of glTF mesh upload.

Join the discussion on Discord!

Feel free to join in the discussion on our Discord which can be found at https://discord.gg/secondlifeofficial

After you’re verified, you can join the content-features channel, or click this link to join: https://discord.com/channels/677442248157167619/968504343911346196

Additionally, you can submit bug reports to Canny (https://feedback.secondlife.com/) or GitHub (https://github.com/secondlife/viewer/issues).

Geenz and others added 30 commits April 8, 2025 13:51
# Conflicts:
#	indra/newview/llviewerdisplay.cpp
Restore option to change location of existing pick
…f std::string_view and heterogeneous map lookups (#3970)
Increment viewer version after 2024.05
…fixes

[#3972] Implemented Texture Panel Repeats per meter improvements and PBR feature
LLAgent::leftButtonGrabbed() must report TRUE only when an attachment has
**actually grabbed** the left mouse button (accept = TRUE, pass_on = FALSE), like every other ...Grabbed() function below it
KDU is uploading 2k files with 7 and 8 layers which is shifting the location of discard 1 and 2.

To accommodate, this commit adds a max_layer check based on max_dimension and the MAX_BLOCK_SIZE to allow the extra layers for 2k.

Also shifted the starting size to the MIN_LAYER_SIZE instead of MAX_BLOCK_SIZE's area to allow smaller files to be decoded at discard 5 completely.

Finally able to walk around Fantasy Faire without any gray blobs!
* updateImageDecodePriority - Avoid Long Face Loop

To avoid running a long loop on thousands of faces, some textures were being set to a BOOST level to avoid the updateImageDecodePriority function entirely but this was causing many of them to never be deleted over the course of a user's travels.

Instead of relying on BOOST, this commit changes the logic of the texture channel loop such that the face loop will only run if the number of faces is below the threshold.

To do this, we move the face_count incrementing outside of the face loop into the channel loop and increment it using the getNumFaces function instead.

We then check the face_count against the maximum number of faces we want to check and if it exceeds the number we set the number of faces for the face loop to check down to zero.

This avoids branch prediction misses and the long face loop issue.

Later, if the face_count is above the threshold, we assign the virtual size to the maximum.

I personally believe the max_faces_to_check should be lower than 1024, but I left that value in for continuity. I use 64 faces as my max on my compiled version of the viewer without any noticeable issues for memory use.

* updateImageDecodePriority - Face Loop Increment Swap

Looks like compilers like knowing the incrementing in the for loop information for optimizations and parallelization.

Sorry for the tiny commit.

* updateImageDecodePriority - Suggested Cleanup

Remove trailing white-space.

Co-authored-by: Andrey Lihatskiy <alihatskiy@productengine.com>
Since these offsets are used for idx[i+offset] where i starts from 0,
they shouldn't be below 0 to not go out of bounds.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.